🌌 Fix for Issue #16

Problem

readFile(path, "utf-8") was ignoring the string encoding parameter and always returning Buffer, inconsistent with Node.js native fs.readFile() behavior.

Root Cause

The Rust function signature only accepted Option<ReadFileOptions> (object form), so when a string was passed:

• readFile("file.txt", "utf-8") → options.encoding was undefined → returned Buffer ❌
• readFile("file.txt", { encoding: "utf-8" }) → worked correctly ✅

Solution

Use NAPI-RS Either<String, ReadFileOptions> to accept both parameter forms:

fn normalize_read_file_options(
  options: Option<Either<String, ReadFileOptions>>,
) -> ReadFileOptions {
  match options {
    Some(Either::A(encoding)) => ReadFileOptions {
      encoding: Some(encoding),  // String → encoding
      flag: None,
    },
    Some(Either::B(opts)) => opts,  // Object → as-is
    None => ReadFileOptions {
      encoding: None,
      flag: None,
    },
  }
}

Changes

• src/read_file.rs: Updated function signatures and added normalization helper
• test/read_file.spec.ts: Added 3 test cases covering:
  • readFile(path, "utf-8") → returns String ✅
  • readFile(path, { encoding: "utf-8" }) → returns String ✅
  • readFile(path) → returns Buffer ✅

Testing

All new tests pass. The API is now fully consistent with Node.js native fs.readFile().

Closes #16

Summary by CodeRabbit

• Tests

  • Added test coverage for file reading operations with various encoding parameter formats, including string encoding and options object variations.

• New Features

  • File reading API now accepts encoding parameters in multiple formats for improved flexibility—either as a direct string or as part of an options object.